1. Field of the Invention
This invention is related to multimedia packet networks. Specifically, this invention relates to a mechanism to allow nodes at the ends of a bearer path within a multimedia packet network to negotiate bearer parameters based on the capabilities of each node, thus facilitating open switching interfaces and reducing the need for provisioning.
2. Description of the Problem
Evolution of the PSTN has accelerated in recent years; however, most of the PSTN still operates on circuit switched, time division multiplexed (TDM) connections. Integrated services digital network (ISDN) bearer channels often provide transport. In parallel with the PSTN, a packet based data network has evolved. This data network has largely been used for Internet traffic and data networking. Although these networks have been mostly separate until recently, the two networks are starting to merge. The merger of these networks requires that voice traffic be carried over packet networks, and further that such packet networks be able to seamlessly integrate with traditional circuit switched networks, as the two types of networks may carry different call legs of the same call.
FIG. 1 illustrates a typical TDM, PSTN call. Caller 101 places a call to callee 105. The call goes through end office A, 102, over some type of trunk bearer channel to toll office 103, then to end office B, 105, and finally to the callee. Such calls may pass through multiple toll offices, or may be connected directly from one end office to another. In any case, a path of circuits for the call is maintained throughout the call. Signaling between offices is typically provided by an ISUP (ISDN user part) connection. ISUP and ISDN signaling are well understood and are standard in the telecommunications industry. For more information on ISUP signaling, see the various International Telecommunications Union (ITU) Recommendations pertaining to telephone signaling, including Q.761, Q.762, Q.763, Q.764 and Q.931, the most recent versions of which at the time of filing this application are incorporated herein by reference.
FIG. 2 illustrates a call that is similar to the TDM call of FIG. 1; however, in this case, the call is transported from one end office to another (called switch offices, 202 and 204, in this case) via a packet switched network 203. This fact is, in theory, transparent to caller 201 and callee 205. ISUP+, which is an extension of ISUP with extra fields for packet or cell based network information, can be used to provide signaling in this case. An International Telecommunications Union (ITU) recommendation was proposed for ISUP+ as ITU Q.1901 (BICC), which was recently published and is incorporated herein by reference. “BICC” stands for “bearer independent call control.” ISUP+ and BICC are inter-changeable. Further details and capabilities of ISUP+ can be found in draft ITU-T Recommendation Q.1902, which is incorporated herein by reference.
Session Initiation Protocol (SIP) is another protocol that is also used to encapsulate ISUP and/or TCAP messages in packets to be used between two MGC based on packet networks. SIP is described in document RFC 2543, published by the Internet Engineering Task Force (IETF), March, 1999 which is incorporated herein by reference. IETF draft document draft-vemuri-sip-t-context-00.txt, known as SIP-T, uses SIP to facilitate the interconnection of the PSTN with packet networks, such as IP and ATM.
Although both BICC and SIP-T can be run over either the IP or ATM networks, practically, BICC is commonly used in the ATM networks and SIP-T is used in the IP networks.
In order for the call leg which is handled by the packet network to seamlessly connect with the call legs handled by TDM switching offices, media provided by one type of network must be converted into media provided by the other. This conversion is referred to as circuit emulation services (CES) in an ATM network. The application is referred to as voice over ATM (VtoA). In the case of an IP network, the application is referred to as voice over IP (VoIP).
The device that provides this media conversion is called a media gateway (MG). In the network of FIG. 2, a MG handles each end of the bearer connection through packet network 203. Each MG is associated with a media gateway controller (MGC). The MG can be stimulus in that it does not have call processing capabilities and is stateless. In that case, the call processing capabilities for the network reside in the MGC. An MGC provides the signaling for call control and controls the call state of a MG. The MG and MGC relationship is referred to as client-server model. Both MG and MGC are referred to as a ‘node’.
There are many media gateway control protocols that can be used by the MGC to control the MG. H.248 Megaco and MGCP are two commonly used media gateway control protocols. Megaco is an application layer protocol which is also described in ITU-T Recommendation H.248, which shares a common text with the IETF standard track RFC 3015 Megaco Protocol, and which is incorporated herein by reference. Throughout the rest of this disclosure, we will refer to Megaco as “Megaco/H.248”. MGCP is an IETF information track RFC 2705. A MGCP variant, Network Call Signaling (NCS), is described in ITU-T Recommendation J.160, which is only used in the cable access networks.
A MG and MGC at the end of a bearer connection form what is known as an integrated node (IN). While the media MG and the MGC were originally envisioned as specific hardware devices, they in fact can be implemented by many combinations of hardware, including multiple devices, cards within a telecommunications frame or one integrated device. Therefore, the integrated node is increasingly being treated as one system containing two logical entities. The MGC corresponds to a logical entity called the call services function (CSF) and the media gateway corresponds to a logical entity called bearer internetworking function (BIWF) in the ITU-T Recommendation Q.1950 BICC.
A MG can also be intelligent. In that case, the intelligent MG has the call processing capability. An intelligent MG does not need a MGC; instead, the intelligent MG communicates with other intelligent MG's directly. This type of MG to MG relationship is referred to as peer-to-peer model. ITU-T Recommendation H.323 IP phone is based on the peer-to-peer model. H.323 is a protocol suite, containing many protocols. Among them, H.245 specifies the call processing functions between two IP phones. The H.323 IP phone needs a Gateway to inter-work with the PSTN networks and a Gate Keeper for call authorization.
In a PSTN, the characteristics of end points (or terminations) are either homogenous or provisioned. There is no need for session establishment or bearer control parameter negotiation in that type of network. However, it is undesirable to provision integrated nodes in a packet network, since widely varying types of equipment from different suppliers may be used to form nodes. Additionally, many more factors are involved in the network connection establishment. The additional factors bring flexibility and functionality to the network; at the same time they also introduce complexity. The possible number of permutations of different factors can make the network connection establishment difficult. For example, the bearer service could be any of various categories of frame relay, asynchronous transfer mode (ATM) application layer (AAL) (AAL1, AAL2, AAL3, AAL4, and AAL5), or Internet protocol (IP) version 4 (Ipv4) or version 6 (Ipv6), or different codecs, or based on other services. Within each bearer type, there are many different possible configuration parameters and values. Ideally, the choice of bearer type and configuration parameters for a given call should be based on either user profiles, or the MG functionality; provisioning should not be required. In addition, between two MG's, many sessions can be established simultaneously. Each session can have its unique configuration. In that case, the configuration parameters for each session need to be communicated either between two MG's, or between a MG and a MGC.
The communications of session configuration parameters can be either informative or negotiable. In the case of informative, the recipient of the configuration information will either accept or reject the configuration parameters, but will not provide further negotiation function with different set of parameters value to establish the call. As a result, the call may be abandoned, even though both ends might have the capabilities to complete the call. The negotiation capability can potentially increase the chance of completing a call.
IETF RFC 2327 Session Description Protocol (SDP) provides the description for configuration parameters. SDP is based on IETF RFC 2234 ABNF syntax. SDP has been used by almost all protocols for communication between two MG's, or between two MGC's, or between a MG and a MGC. SIP, BICC, H.248, MGCP, NCS, H.323/H.245, Q.1950, and Q.1990 all use SDP for session parameter descriptions. Most of these protocols provide the informative function rather than a negotiation function. There is seldom any negotiation capability between two MG's, either directly or indirectly (such as through the MGC's). What is needed is a way to efficiently negotiate bearer channel type and parameters between two nodes within a multimedia packet network that can work with protocols that do not provide for direct negotiation. The negotiation should be based on the capabilities of each MG or MGC and should use as little bandwidth as possible on connections between nodes. The negotiation can be defined by user profiles, or by the hardware and software installed at the node.
This invention also provides session configuration negotiation in SDP. There is no limitation on how this invention can be applied with different protocols, which use SDP. Various protocols, such as SIP, BICC, H.248, MGCP, NCS, H.323/H.245, Q.1950, and Q.1990, can use this invention.